Redis cluster实验多master写入、主从复制、高可用性

发布 : 2017-06-26 分类 : 大数据 浏览 : 
1
2
3
4
5
redis cluster，提供了多个master，数据可以分布式存储在多个master上;

每个master都带着slave，自动就做读写分离

每个master如果故障，那么就会自动将slave切换成master，高可用
1
2
3
4
5
redis cluster，提供了多个master，数据可以分布式存储在多个master上

每个master都带着slave，自动就做读写分离

每个master如果故障，那么久会自动将slave切换成master，高可用

实验多master写入 -> 海量数据的分布式存储

1
2
3
4
5
6
7
8
9
10
11
12
13
在redis cluster写入数据的时候，其实是你可以将请求发送到任意一个master上去执行

但是，每个master都会计算这个key对应的CRC16值
然后对16384个hashslot取模
找到key对应的hashslot
找到hashslot对应的master

如果对应的master就在自己本地的话，set mykey1 v1
mykey1这个key对应的hashslot就在自己本地，那么自己就处理掉了

但是如果计算出来的hashslot在其他master上
那么就会给客户端返回一个moved error，告诉你
你得到哪个master上去执行这条写入的命令

写数据

1
2
3
[root@matrix-cache01 ~]# redis-cli -h 192.168.31.231 -p 7001
192.168.31.231:7001> set key1 v1
(error) MOVED 9189 192.168.31.232:7003
1
2
3
[root@matrix-cache02 ~]# redis-cli -h 192.168.31.232 -p 7003
192.168.31.232:7003> set key1 v1
OK

读数据

1
2
3
[root@matrix-cache01 ~]# redis-cli -h 192.168.31.231 -p 7001
192.168.31.231:7001> get key1
(error) MOVED 9189 192.168.31.232:7003
1
2
3
[root@matrix-cache02 ~]# redis-cli -h 192.168.31.232 -p 7003
192.168.31.232:7003> get key1
"v1"

什么叫做多master的写入

1
每条数据只能存在于一个master上，不同的master负责存储不同的数据，分布式的数据存储
1
100w条数据，5个master，每个master就负责存储20w条数据，分布式数据存储
1
2
3
4
5
6
7
8
9
10
11
大型的java系统架构，还专注在大数据系统架构
分布式存储：hadoop hdfs
分布式资源调度：hadoop yarn
分布式计算：hadoop mapreduce/hive

分布式的nosql数据库：hbase
分布式的协调：zookeeper
分布式通用计算引擎：spark
分布式的实时计算引擎：storm

如果你要处理海量数据，就涉及到了一个名词，叫做大数据，只要涉及到大数据，那么其实就会涉及到分布式
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
redis是作为大规模缓存架构中的底层的核心存储的支持

高并发、高性能、每日上亿流量，redis持久化 ->
灾难的时候，做数据恢复，复制 ->
读写分离，扩容slave，支撑更高的读吞吐

redis怎么支撑读QPS超过10万，几十万?
哨兵，在redis主从，一主多从，怎么保证99.99%可用性;
redis cluster，海量数据

elasticsearch建立索引的时候
先写内存缓存，每秒钟把数据刷入os cache
再每隔一定时间fsync到磁盘上去

redis cluster，写可以到任意master
任意master计算key的hashslot以后
告诉client，重定向，路由到其他mater去执行，分布式存储的一个经典的做法

jedis cluster api，就可以自动针对多个master进行写入和读取

实验不同master各自的slave读取 -> 读写分离

查看slave

1
2
3
4
5
6
7
8
9
10
11
12
[root@matrix-cache02 ~]# redis-cli -h 192.168.31.232 -p 7003
192.168.31.232:7003> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.31.233,port=7006,state=online,offset=10569,lag=1
master_repl_offset:10569
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:10568
192.168.31.232:7003> exit

在slave中读取数据

1
2
在这个redis cluster中，如果你要在slave读取数据
那么需要带上readonly指令，get key1
1
2
3
4
5
6
7
8
[root@matrix-cache03 ~]# redis-cli -h 192.168.31.233 -p 7006
192.168.31.233:7006> get key1
(error) MOVED 9189 192.168.31.232:7003
192.168.31.233:7006> readonly
OK
192.168.31.233:7006> get key1
"v1"
192.168.31.233:7006> exit
1
redis-cli -c启动，就会自动进行各种底层的重定向的操作
1
2
3
4
[root@matrix-cache02 ~]# redis-cli -h 192.168.31.232 -p 7003 -c
192.168.31.232:7003> get key1
"v1"
192.168.31.232:7003> exit
1
2
3
实验redis cluster的读写分离的时候，会发现有一定的限制性，默认情况下，redis cluster的核心的理念，主要是用slave做高可用的，每个master挂一两个slave，主要是做数据的热备，还有master故障时的主备切换，实现高可用的

redis cluster默认是不支持slave节点读或者写的，跟我们手动基于replication搭建的主从架构不一样的
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
slave node，readonly，get，这个时候才能在slave node进行读取

redis cluster，主从架构是出来，读写分离，复杂了点，也可以做，jedis客户端，对redis cluster的读写分离支持不太好的

默认的话就是读和写都到master上去执行的

如果你要让最流行的jedis做redis cluster的读写分离的访问，那可能还得自己修改一点jedis的源码，成本比较高

要不然你就是自己基于jedis，封装一下，自己做一个redis cluster的读写分离的访问api

核心的思路，就是说，redis cluster的时候，就没有所谓的读写分离的概念了

读写分离，是为了什么，主要是因为要建立一主多从的架构，才能横向任意扩展slave node去支撑更大的读吞吐量

redis cluster的架构下，实际上本身master就是可以任意扩展的，你如果要支撑更大的读吞吐量，或者写吞吐量，或者数据量，都可以直接对master进行横向扩展就可以了

也可以实现支撑更高的读吞吐的效果

不会去跟大家直接讲解的，很多东西都要带着一些疑问，未知，实际经过一些实验和操作之后，让你体会的更加深刻一些

redis cluster，主从架构，读写分离，没说错，没有撒谎

redis cluster，不太好，server层面，jedis client层面，对master做扩容，所以说扩容master，跟之前扩容slave，效果是一样的

实验自动故障切换 -> 高可用性

1
2
3
4
5
6
7
8
redis-trib.rb check 192.168.31.232:7003

比如把master2，232:7003，kill 掉，
看看它对应的233:7006能不能自动切换成master，可以自动切换

切换成master后的233:7006，可以直接读取数据

再试着把232:7003给重新启动，恢复过来，自动作为slave挂载到了233:7006上面去

查看master的slave

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@matrix-cache02 ~]# redis-cli -h 192.168.31.232 -p 7003
192.168.31.232:7003> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.31.233,port=7006,state=online,offset=33235,lag=0
master_repl_offset:33235
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:33234
192.168.31.232:7003> set mykey3 vv2
OK
192.168.31.232:7003> get mykey3
"vv2"
192.168.31.232:7003> exit

kill掉master

1
2
3
4
5
6
7
8
9
10
11
[root@matrix-cache02 ~]# ps aux | grep redis
root       882  0.1  0.1  31144  1840 ?        Ssl  Jun26   0:26 /usr/local/bin/redis-server 192.168.31.232:6379
root       943  0.1  0.2  33652  2544 ?        Ssl  Jun26   0:41 /usr/local/bin/redis-server 192.168.31.232:7003 [cluster]
root       948  0.1  0.2  31604  2336 ?        Ssl  Jun26   0:41 /usr/local/bin/redis-server 192.168.31.232:7004 [cluster]
root      1229  0.0  0.0   5976   764 pts/0    S+   04:28   0:00 grep redis
[root@matrix-cache02 ~]# kill -9 943
[root@matrix-cache02 ~]# ps aux | grep redis
root       882  0.1  0.1  31144  1840 ?        Ssl  Jun26   0:26 /usr/local/bin/redis-server 192.168.31.232:6379
root       948  0.1  0.2  31604  2336 ?        Ssl  Jun26   0:41 /usr/local/bin/redis-server 192.168.31.232:7004 [cluster]
root      1231  0.0  0.0   5976   764 pts/0    S+   04:28   0:00 grep redis
[root@matrix-cache02 ~]# rm -rf /var/run/redis_7003.pid

观察slave是否变成master

1
2
3
4
5
6
7
8
9
10
11
12
13
[root@matrix-cache03 ~]# redis-cli -h 192.168.31.233 -p 7006
192.168.31.233:7006> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
192.168.31.233:7006> get mykey3
"vv2"
192.168.31.233:7006> exit
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@matrix-cache02 ~]# redis-cli -h 192.168.31.232 -p 7003
192.168.31.232:7003> info replication
# Replication
role:slave
master_host:192.168.31.233
master_port:7006
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:99
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
192.168.31.232:7003> exit

查看集群效果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[root@matrix-cache01 ~]# cd /usr/local
[root@matrix-cache01 local]# redis-trib.rb check 192.168.31.231:7001
>>> Performing Cluster Check (using node 192.168.31.231:7001)
M: 2891dbe63dafb4ab19a525ef52b8d6c7ce81f697 192.168.31.231:7001
   slots:10923-16383 (5461 slots) master
   1 additional replica(s)
M: b77a3468b04230a351ebb1d35e73ab8d8927ef6a 192.168.31.233:7006
   slots:5461-10922 (5462 slots) master
   1 additional replica(s)
M: 6db546298ea36dddcccd94b72082939942bf161c 192.168.31.233:7005
   slots:0-5460 (5461 slots) master
   1 additional replica(s)
S: abfe6bb4873332990a6069c6e4059a406df16e33 192.168.31.232:7003
   slots: (0 slots) slave
   replicates b77a3468b04230a351ebb1d35e73ab8d8927ef6a
S: a07ca619c37dcb437bcb55b4ee04156a1f78f9d9 192.168.31.231:7002
   slots: (0 slots) slave
   replicates 2891dbe63dafb4ab19a525ef52b8d6c7ce81f697
S: ce3b38c239bf708effdb057b962bdf392f7ecb83 192.168.31.232:7004
   slots: (0 slots) slave
   replicates 6db546298ea36dddcccd94b72082939942bf161c
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

Markdown

本文作者 : Matrix
原文链接 : https://matrixsparse.github.io/2017/06/26/Redis cluster实验多master写入、主从复制、高可用性/
版权声明 : 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明出处！

知识 & 情怀 | 二者兼得

微信扫一扫, 向我投食

微信扫一扫, 向我投食

支付宝扫一扫, 向我投食

支付宝扫一扫, 向我投食

标签: #大数据 #Redis
留下足迹